Creating valuable application programs requires more than just programming ability. There is an increasing appreciation for the need for aesthetics and ease of use in the design of user interfaces. To term the new user interfaces design strategies in cutting edge software as being “ergonomic” is not an overstatement. The rapid rate of obsolescence in software has further increased the pressure to create increasingly sophisticated application programs complete with bug free code and friendly interfaces in a short period of time or risk missing the small window of economic opportunity.
A typical traditional application program has a source code, which is usually organized in several modules. Following compilation, these modules are linked to form an executable program. This simplistic picture is modified significantly in the modem programming paradigm. Thus, in the popular “WINDOWS®” operating system environment found in operating systems manufactured by the “MICROSOFT®” corporation of Redmond, Wash., application development typically requires generation of several different files types that cooperate to give effect to an application. The details of the file types actually used depend on many factors including the actual source code used. Thus, for example, an application written in C++ may have several resource files, with file extension .RC, while in contrast, a program written in Visual Basic can have only one resource file with a different file extension.
A “WINDOWS®” application program typically has an executable file that generally creates, directly or indirectly by making appropriate calls, one or more “WINDOWS®” elements to implement a user interface. Communications between different parts of the application and the operating system use the message facility provided by the operating system. Optionally, function calls can also be made to effect communications. The message facility conveniently allows user input generated events to be handled at different levels while allowing the application to communicate with the “WINDOWS®” elements to format and control their properties.
In addition, unlike earlier programming styles, in a “WINDOWS®” environment, there are files with code modules such as dynamic link library (DLL) files, resource files, library files and other file types that are used to generate an application. A respectable application may depend on thousands of files to handle the different scenarios that may develop in course of its execution. These files are usually compiled individually and linked at various stages in the development and execution of the application. Presently, such files are compiled to generate binaries that are integrated into the application at each stage. The shipped application is an integrated package of a plurality of compiled binary files for installation and execution of the entire package. Of particular interest are the resource files that include information relevant to the design and implementation of the graphical elements shown on the screen.
When an application uses a routine in a “DLL” file, the operating system loads the DLL file into memory, resolves references to functions in the DLL file so that they can be called by the application, and unloads the DLL file when it is no longer needed. This dynamic linking mechanism can be performed explicitly by applications or implicitly by the operating system. The advantage in using several DLL files is that if an error in a file needs to be corrected, the entire code does not need to be recompiled. Instead only the relevant file is corrected and recompiled. Furthermore, the entire executable code does not have to be loaded at runtime as individually compiled DLL files are loaded as needed. DLL files can also be used to allow independent resource files to be created often have their own data address space mapped into the address space of the process.
Although resource files contain data, such as parameters, bitmaps for icons, font and color choices and the like for rendering graphical symbols, they cannot be treated as merely data files that may be accessed at runtime due to their dynamic use in giving effect to the user interface. Some user interface elements, i.e., “WINDOWS®” elements, of interest include dialog boxes, message boxes, drop-down lists, menus, toolbars even audio effects. Each user interface element needs to be invoked at the right time and place with modifications for accomplishing a particular purpose.
Some user interface elements convey information to the user while others also collect information, and all, preferably, add to the experience of the user. The placement and details of the design implementation are preferably controlled by parameters supplied in resource files, which may be edited with the help of programming tools and resource editors, available in some environments, or by directly modifying the application source code. However, such programming tools or resource editors cannot be used to change the appearance of an application while it is executing. Moreover, use of the programming tools and editors requires considerable training and technical knowledge since, potentially, rest of the application source code could be corrupted by what may appear to be minor errors to the uninitiated.
This, in turn, has resulted in focusing attention on the process of designing and developing application programs. As may be expected, cost is an important consideration in the development of improved computer programs. Programmers skilled in writing code for applications are expensive, and programmers having an additional feel for the aesthetic needs of the ordinary consumer are even more precious. Consequently, in developing an application a division of labor between the “designers” and the “developers” has proven to be cost effective. Developers specialize in coding, debugging and similar programming related tasks while “designers” are so designated due to their skill in designing the look and feel of an application. Many designers lack the coding prowess of the average developer and conversely, many developers lack the presentation skills that a designer brings to the job.
A common difficulty in managing such a diverse team is the need for the developers to implement the smallest changes made by the designers as they experiment with different layouts. Each time the designers try out a new look in course of settling on an effective layout, the developers modify the application code, compile and link the code and then call on the designers to evaluate the result.
Apart from the need for countless meetings between designers and developers, the time taken in developing an application includes several cycles, termed “build,” each build typically taking two to three days. At the end of a build the different component parts of an application are ready to be operated together (as opposed to being tested separately. Thus, desirable management of the application development process preferably reduces the tedium for the developers while leaving the designers unfettered and, at the same time, reducing costs and the time required for getting the application ready for shipping.
Another situation that results in the need for modifying primarily the user interface in an otherwise finished application is while porting the application from one linguistic and cultural context to another. This may result in changes in the size, associated text and appearance of the graphical controls to accommodate text, larger or smaller fonts, handedness, different designs and the like. Some parameters are relatively invariant within a particular context and can be provided as defaults. An application for a U.S. patent application Ser. No. 09/506,125 teaches providing sensible defaults and strategies for reducing coding complexity in implementing resource files to provide details in conformity with accepted, and/or desired, styles and is incorporated by reference.